Repository navigation
systemvmtemplate: bump to Debian 13 'trixie' and ACS 24.0 - #12912
weizhouapache wants to merge 17 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #12912 +/- ##
============================================
+ Coverage 20.21% 20.67% +0.45%
- Complexity 20750 21726 +976
============================================
Files 6426 6492 +66
Lines 580181 590737 +10556
Branches 71033 72448 +1415
============================================
+ Hits 117287 122121 +4834
- Misses 450180 455343 +5163
- Partials 12714 13273 +559
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
failed to build new systemvm template, revisit later |
weizhouapache
changed the title
|
there are several big changes with debian 13, it looks more time is required: |
47130b5 to
3d91402
Compare
9db392e to
0300e07
Compare
- use openjdk-21-jre-headless, as openjdk-17-jre-headless is not available in Debian 13 - drop software-properties-common, which is not available in Debian 13 - configure the Docker apt repository with a keyring in /etc/apt/keyrings and a sources.list.d entry instead of apt-key and add-apt-repository; use VERSION_CODENAME from /etc/os-release instead of lsb_release - install chrony in the preseed files, as the ntp package is not available in Debian 13 - do not fail if /etc/apt/sources.list does not exist, and add the backports and security repositories in sources.list.d - disable the cloud-init units that exist, as cloud-init.service no longer exists and stopping it failed the build
|
@blueorangutan package all |
weizhouapache
changed the title
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 19575 |
For 24.x and later the systemvm templates are published in a directory named after the major version, with the major.minor version in the file names (24/systemvmtemplate-24.0-x86_64-kvm.qcow2.bz2), instead of major.minor and major.minor.patch (4.22/systemvmtemplate-4.22.0-...).
… script For 24.x and later, templateConfig.sh generates metadata.ini with the templates in the directory named after the major version and with major.minor in the file and template names (24/systemvmtemplate-24.0-..., systemvm-kvm-24.0-x86_64), so that the checksums are found in sha512sum.txt. The version in metadata.ini is unchanged (24.0.0). export-templates.sh uses major.minor for the template file names too. Legacy (4.x) behavior is unchanged. Tests are updated and extended.
e9503f9 to
405cdf4
Compare
|
@blueorangutan test matrix |
|
@weizhouapache a [SL] Trillian-Jenkins matrix job (ol8 mgmt + kvm-ol8, ubuntu22 mgmt + kvm-ubuntu22, ol8 mgmt + vmware-70u3, ol9 mgmt + xcpng82) has been kicked to run smoke tests |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✖️ suse15. SL-JID 19577 |
|
[SF] Trillian test result (tid-17270)
|
|
[SF] Trillian test result (tid-17257)
|
Sure, will review this @weizhouapache . quick check about the failed smoke tests, are they related here ? |
thanks @harikrishna-patnala it looks like the test failures are not consistent, so most are intermittent (except test_04_readiness_cache_invalidated_on_out_of_band_restart on xcpng, I think it is caused by the user template used in the test) |
|
@blueorangutan test matrix |
|
@weizhouapache a [SL] Trillian-Jenkins matrix job (ol8 mgmt + kvm-ol8, ubuntu24 mgmt + kvm-ubuntu24, ol8 mgmt + vmware-70u3, ol9 mgmt + xcpng82) has been kicked to run smoke tests |
|
Thanks @weizhouapache - let's check the test matrix results after these jobs finish |
|
[SF] Trillian test result (tid-17288)
|
init.sh runs before dbus is started on a slow boot, e.g. on XenServer, so hostnamectl fails and the hostname stays 'systemvm'. The agent then registers the system VM with that name and its agent state is not shown.
run manually |
|
[SF] Trillian test result (tid-17289)
|
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19795 |
|
@blueorangutan test matrix |
|
@weizhouapache a [SL] Trillian-Jenkins matrix job (ol8 mgmt + kvm-ol8, ubuntu24 mgmt + kvm-ubuntu24, ol8 mgmt + vmware-70u3, ol9 mgmt + xcpng82) has been kicked to run smoke tests |
|
@blueorangutan test matrix keepEnv |
|
@weizhouapache a [SL] Trillian-Jenkins matrix job (ol8 mgmt + kvm-ol8, ubuntu24 mgmt + kvm-ubuntu24, ol8 mgmt + vmware-70u3, ol9 mgmt + xcpng82) has been kicked to run smoke tests |
|
[SF] Trillian Build Failed (tid-17306) |
|
[SF] Trillian test result (tid-17291)
|
DaanHoogland
left a comment
DaanHoogland
left a comment
There was a problem hiding this comment.
looking good so far, 😨
| project.properties.setProperty('cs.version', versionParts[0] + "." + versionParts[1]) | ||
| project.properties.setProperty('patch.version', versionParts[2]) | ||
| if (versionParts[0].toInteger() >= 24) { | ||
| // new versioning: directory 24, templates systemvmtemplate-24.0-... |
There was a problem hiding this comment.
| // new versioning: directory 24, templates systemvmtemplate-24.0-... |
| project.properties.setProperty('cs.version', versionParts[0]) | ||
| project.properties.setProperty('patch.version', versionParts[1]) | ||
| } else { | ||
| // legacy versioning: directory 4.22, templates systemvmtemplate-4.22.0-... |
There was a problem hiding this comment.
| // legacy versioning: directory 4.22, templates systemvmtemplate-4.22.0-... |
|
[SF] Trillian test result (tid-17308)
|
|
[SF] Trillian test result (tid-17311)
|
|
[SF] Trillian test result (tid-17307)
|
|
[SF] Trillian test result (tid-17309)
|
Description
This PR duplicates #11535 and bumps the systemvm template to Debian 13 'trixie' (ACS 24.0). The template of Debian 13 differs from Debian 12 in several places, so the PR also fixes what broke when the system VMs, the CKS nodes and the shared filesystem VMs run on it.
Template build (
tools/appliance)openjdk-21-jre-headlessinstead ofopenjdk-17-jre-headlesssoftware-properties-common, and set up the Docker apt repository with a keyring in/etc/apt/keyringsand asources.list.dentry (noapt-key,add-apt-repositoryorlsb_release)/etc/apt/sources.listdoes not exist, and add the backports and security repositories insources.list.dntpsecinstead ofntp(thentppackage does not exist in Debian 13).setup_ntpconfigures/etc/ntpsec/ntp.conf, so withchronythe NTP servers of the console proxy and secondary storage VMs were not appliedcloud-init.servicedoes not exist in cloud-init 25.1, and disabling it failed the build)isc-dhcp-clientis installed. See "cloud-init" below.Template files and metadata (
engine/schema,scripts/installer)24/systemvmtemplate-24.0-x86_64-kvm.qcow2.bz2), instead of4.22/systemvmtemplate-4.22.0-....templateConfig.sh, the pom andexport-templates.shuse the new names so thatmetadata.inifinds the checksums insha512sum.txt. The behaviour for 4.x is unchanged, andtest_templateConfig.shis extended.System VM scripts (
systemvm/debian)bootstrap.sh: create/etc/iproute2/rt_tablesfor all the system VM types, because iproute2 in Debian 13 does not install it any more, and adding the route table of a NIC failed withFileNotFoundErrorwhen the VR was configured.common.shandvpcrouter.sh:hostnamectl set-hostnamefails wheninit.shruns before dbus is started, which happens on a slow boot, e.g. on XenServer. The hostname then stayssystemvm, the agent registers the system VM with that name and its agent state is not shown. The hostname is set withhostnameifhostnamectlfails.passwd_server_ip.py: thecgimodule was removed in Python 3.13, which is used by Debian 13, socloud-password-serverfailed to start (No module named 'cgi') and the VMs could not get their passwords. The POST ofsavepassword.shis parsed with theemailpackage instead, andapplication/x-www-form-urlencodedis accepted too. Unit tests are added inTestPasswdServerIp.py.cloud-init on the CKS nodes and the shared filesystem VMs
The user data of these VMs is applied by cloud-init. On Debian 13 it was never applied, so the CKS nodes were not set up and the shared filesystem VMs did not start NFS (the mount got
Connection refused). There were four separate reasons:cloud-init.service.cloud-init-mainruns all the stages, andcloud-init-local,cloud-init-network,cloud-configandcloud-finalhand over to it.start_cloud_initandstop_cloud_initincommon.shstart and stop the new units (the old ones are still used ifcloud-init-maindoes not exist) and are used bycksnode.shandsharedfsvm.sh./etc/cloud/cloud-init.disabled, and the units of cloud-init 25.1 are skipped by systemd while that file exists.start_cloud_initremoves the file (and the marker written by the generator at boot) and reloads systemd, andstop_cloud_initcreates it again.dhclientis missing. The setup scripts calldhclient, and the shared filesystem VM startscloud-dhclient@eth0.service, which runs/usr/sbin/dhclient. Without it the DHCP options (DNS server of the virtual router, domain) are not applied,/etc/resolv.confkeeps the static name servers of the zone,data-servercannot be resolved and cloud-init does not find the metadata server, andcloud-dhclient@eth0.servicefails with 203/EXEC.isc-dhcp-clientis installed in the template, like it was in the Debian 12 template.dhcpcdfirst for the DHCP lease, anddhcpcdis not running in the system VMs.dhcpcd --dumpleaseneeds a running daemon, so the lookup fails withNoDHCPLeaseError, which the CloudStack datasource does not catch, so the init stage fails and no datasource is found.network.dhcp_client_priorityis set todhclientfirst in the cloud-init configuration of the template.dhclientreads a lease file, and returns no lease instead of raising.The cloud-init settings which the setup scripts of the CKS nodes apply at start (
policy: enabledin/etc/cloud/ds-identify.cfg, andConfigDriveandCloudStackindatasource_list, see #7650) are also put in the cloud-init configuration of the template. cloud-init stays disabled by default.cloud-init must stay at 25.1.x (25.1.4 in Debian 13). From 25.2 the CloudStack datasource only runs when the DMI product name starts with
CloudStack(canonical/cloud-init@589c9461db, #6144). The product name isCloudStack KVM Hypervisoron KVM, butVMware Virtual Platformon VMware and a Xen value on XenServer, so the user data would not be applied there. The template therefore has to keep the cloud-init of Debian 13 and must not upgrade it to 25.2 or newer.Tests
test_network_ipv6andtest_vpc_ipv6: nftables 1.1.3 (Debian 13) prints the ICMPv6 code name only for some types and the number for the others (icmpv6 type ind-neighbor-advert icmpv6 code 4), so the tests failed depending on the random type and code. Both the name and the number are accepted.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
The template was built from this branch and registered as the system VM template on four Trillian environments:
test_sharedfs_lifecycletest_kubernetes_clustersBefore the cloud-init changes, the shared filesystem VMs and the CKS nodes did not get their user data on any of the four environments (NFS refused the mount, and the clusters were not set up).
On XCP-ng the CKS cases
test_02_upgrade_kubernetes_cluster(the upgrade step of the control node fails) andtest_08_upgrade_kubernetes_ha_cluster(the HA cluster does not get the nodes in the Ready state) fail. Clusters with a single control node are deployed, scaled, autoscaled and deleted by the same template, so I do not think the template is the cause, but I did not find the cause yet.How did you try to break this feature and the system with this change?